The dialWebRTC function created multiple Transport instances and signaling service clients during connection setup; however, the client retained only the final WebRTC data channel transport, which caused a few issues.

HTTP/2 connection pool buildup

createGrpcWebTransport from @connectrpc/connect-web creates HTTP/2 connections. The Transport uses fetch, and the browser manages persistent connections in its connection pool. By reusing a single Transport instance, we enable the browser to reuse the same underlying HTTP/2 connection for multiple requests to the same origin, rather than potentially creating multiple connection contexts through separate 'Transport' objects.

Memory leaks from abandoned transport states

Transport instances hold internal state (connection pools, request queues, event handlers, authentication headers).
The transport from getOptionalWebRTCConfig was never explicitly closed. The Transport object goes out of scope, but its internal state may persist until the garbage collector runs. With frequent reconnections, this accumulates.

Port exhaustion on frequent reconnects

We created multiple Transport objects for each connection attempt, which could open numerous TCP connections, each consuming a temporary local port. During rapid reconnections, these ports might not be released fast enough, risking port exhaustion. By creating and reusing a single Transport instance, the browser can efficiently manage a single underlying connection and its port, eliminating the risk of exhaustion.

Multiple connections to the signaling service

We were creating two separate client connections to the signaling server: one for optionalWebRTCConfig and one for signaling exchange. These changes create a singleTransport which means one connection handles both operations, reducing server load and connection overhead.